@shemnon Please take a look. This is consistent with the JSON-RPC. We have to return yParity for type-1 and type2 transactions instead of v. (More context: paradigmxyz/reth#3798)

Looks reasonable.

Why Long over BigInt? JSON-RPC encodes yParity as a uint not a uint64, and Long limits to 64. It's not an input parameter so queries passing in numbers shouldn't matter.

Given that r, s and v are also BigInt I tend to agree 👍

Come to think of it, v should become nullable. It will be null for type-1 and type-2 txes.

we also need to merge #468 which impacts the graphql apis.

The value of yParity is always 0 or 1. So it makes no sense for it to be a BigInt. There are only two possible values in responses: 0x0 or 0x1. Not sure how this could be encoded into the schema.

The argument for BigInt is for consistent handling with mappings from the JSON-RPC api, because it is just uint there which maps to BigInt for r and s. Long is to much as well. What is really needed is a type that means "hex integer output" which is what BigInt fulfills.